Revision 589: Neues in HTML und Co, Teil 3 von 3

Transcript

[0:00] Also, kannst du mir den Use-Case noch mal erklären? Ich hab das nicht ganz verstanden, wofür ich das Model-Element haben möchte.
Das ist eigentlich so was wie eine WebGL-Canvas oder eine, was benutzt man mittlerweile, WebGPU-Canvas, nur eben in Markup-Form und dann eben mit der Möglichkeit, dass man nur sagt, Browser, hier ist 3D, ein 3D-Raum für die Vision Pro.
Ihr seid dran, ich kann jetzt ja eh nix mehr machen.
Canvas plus ein Soundrummer rum.
Genau.
Es heißt also jetzt Pre-Render, aber es rendert nicht mehr pre.
Ja, genau. Okay, das passt gut in die Webentwicklung rein, find ich. Ja, so ist es.

[0:42] Music.

[1:08] Revision 589. Und da sind wir wieder mit unserem State-of-HTML.

Revision 589: Neues in HTML und Co, Teil 3 von 3

https://workingdraft.de/589/

[1:45] Wir versuchen mal, heute zu einem Ende zu kommen. Mit dabei ist, wie die letzten beiden Male, der Peter.
Moin, moin. Und ich bin der Shep. Und wir machen da weiter, wo wir zuletzt aufgehört haben.
Bzw. beim nächsten Topic. Wir hatten zuletzt Client-Hints.
Und jetzt haben wir hier die Resource-Hints.
Ist, glaube ich, auch schon so ein relativ, also kein ganz neuer Root mehr, würde ich sagen, oder?
Nee, noch eine kurze Erklärung. Das sind diese REL-Attribute, die ich auf irgendwelche externen Ressourcen, die ich mit Link einbinde, mache, ne?
Mh.

[2:27] Genau, also Prefetch, Preconnect und Preload und dann vielleicht Prerender, das ist nochmal so ein Kandidat, über den können wir sprechen.
Denn Prerender gab es ja schon auch vor Äonen und wir haben da sicherlich auch drüber gesprochen.
Aber das funktionierte damals so, dass die Chromium-Browser-Seiten im Hintergrund, komplett schon vorgerendert haben, weswegen so Analytics-Tools dann auch so Abfragen auf Page-Visibility einführen mussten, um nicht zu zählen, wenn jemand eben eine geprerenderte Seite geöffnet hat, sondern erst dann zu zählen, wenn diese geprerenderte Seite auch dann sichtbar wurde. Aber das wurde dann irgendwann wieder eingestampft, weil das halt relativ ressourcenintensiv Also, ich meine, du konntest das immer nur für eine Seite machen.
Aber im Worst-Case bedeutete das, mit jeder Seite, die du eben aufrufst und betrachtest, wird immer noch mal eine zusätzliche Seite komplett mit all ihren Ressourcen im Hintergrund aufgerufen und auch im Hintergrund geprerendert.

[3:40] Das ist zwar dann toll, wenn man just zu dieser Seite dann weiterbrowst, dann konnte der Browser die eben einfach, direkt anzeigen.
Aber in der Gesamtbilanz war das irgendwie nicht so cool. Und darum wurde das wieder eingestampft, aber es ist wieder zurück, vielleicht irgendwie seit drei, vier Jahren oder so was.
Und was jetzt passiert ist, dass das quasi ein Prefetch-Deluxe ist.
Also, der Browser geht eben jetzt hin, das ist auch wieder die Chrome-Browser, und holt das HTML-Element, äh, Dokument, und passt das dann, aber der Ressourcenscanner geht dann da durch und holt dann wiederum noch mal die ganzen Subressourcen, die da drin sind.
Das heißt also, dieses ganze Ressourcenfetchen, dieser ganze Rattenschwanz, der steckt eben weiterhin jetzt in diesem Prerender drin.
Aber das letztendliche Rendern selbst, das findet nicht mehr statt.
Das ist dann erst, wenn du die Seite dann auch öffnest.
Das heißt also, jetzt Prerender, aber es rendert nicht mehr pre.

[4:44] Ja, genau. Okay, das passt gut in die Webentwicklung rein, finde ich. Ja, so ist es.
Ich meine, das ist schon irgendwie ein bisschen ein seltsamer Ansatz. Also, nur weil du halt irgendwie eine einigermaßen lineare Seitenstruktur hast, also ich meine, es ist ja so, also entweder hast du dann einfach was, was einfach so gebrowst wird wie Wikipedia, Der macht ja relativ wenig Sinn, weil du weißt ja nie, auf welchen von den vielen Links der Mann als nächstes klickt.
Aber schon wenn du irgendwie so in die Richtung von so, keine Ahnung, in der Newsseite oder so gehst, die einigermaßen halb Seiten ist, dann versuchen sie dich ja schon in den nächsten Artikel reinzuschieben, damit du schön durchklickst.

[5:28] Und sozusagen, was ja ohnehin schon so ein bisschen nach Manipulation riecht, so ein bisschen.
Und dann halt auch noch zu sagen, sozusagen, die Kosten, um das auch noch möglichst smooth zu machen, bürden wir dir auch noch auf.
Kosten jetzt ein bisschen in Air-Quotes, weil wegen des ganzen Pre-Rendern, so Fashions und so.
Aber das kann der Client auch noch machen, dass man es denen auch noch leichter macht.
Ist ja alles ein bisschen fishy. Man könnte auch gucken, ob man noch mal hinschaut, ob die Bilder schneller laden.

[5:53] Teilgröße reduzieren oder so. Es hört sich für mich immer so an, du bist der Performance-Pups, nicht ich. Aber immer so Sachen wie dieses ganze.

[6:01] Ein paar Attribute verteilen, um wirklich das Feintuning zu machen, daran, was jetzt als nächstes in welcher Reihenfolge gefetcht wird.
Klingt für mich immer, als würde man da vergleichsweise viel mentale Energie reinstecken und sehr viel fummeln, wo man eventuell ja auch einen ähnlichen Speedup erreichen könnte, indem man schaut, hab ich eigentlich Treeshaking wirklich an?
Oder ist das Bild wirklich kontinuiert?
Ja, genau, das sind dann vielleicht so Sachen, die man zum Schluss, wenn man alles andere abgeklappert hat, noch machen kann.
Ähm, genau. Ich benutze eigentlich Prerender auch nie, weil eben in der Regel, dass man kein lineares Navigieren hat, wo klar ist, wo jemand hinkommt.
Also, du könntest natürlich sagen, per Intersection Observer oder beim Mouse-Hover oder so, dann sagst du eben, der Link ist gerade im Viewport oder die Maus bewegt sich darauf zu.
Und dann erzeuge ich eben schnell so ein Pre-Render-Gerät, das ich in Stom einhänge.
Und dann kann der Browser schon mal irgendwie losrennen.
Und wenn die Besucherin oder Besucher dann tatsächlich diesen Link aufruft, dann habe ich was gewonnen.
Das geht also. Du hast gerade gesagt, so einen Prerender kann ich nur einen haben.
Aber das verstehe ich jetzt als, ich kann zu jedem Zeitpunkt immer nur eine pre-gerenderte Kugel in der Kanone haben.

[7:25] Aber ich kann die ... Du kannst es auswechseln. Aber vielleicht täusche ich mich auch.
Vielleicht ist das auch mittlerweile gar nicht mehr der Fall.
Das gucken wir direkt mal nach.
MDN, Prerender, mal sehen, ob wir das hier haben.
Aha. Rel, Prerender, da, aus April. Ah, Deprecated, okay. Non-Standard, hm.
Tja.
Vielleicht ist es ja auch schon wieder kaputtgegangen. Moment.
Aber in Chrome ist es auf jeden Fall noch aktiv.
Und tja, mehr steht da nicht. Ja, müsste man nochmal, Web, Web.dev war das?
Prerender, das ist doch hier.
Web.dev. Das ist, wenn man die Sachen sucht, die wirklich irgendwie sehr randständig sind.
Genau, wobei ich jetzt zu developer.chrome.com gekommen bin.
So, und bla bla bla. Es scheint wirklich keine Spezifikation dafür zu geben.
Nee.
Äh, so.

[8:31] Ah ja, genau. Ah ja, du kannst jetzt auch noch so, ah, es gibt noch so the Speculation Rules API.
Stimmt, die kamen dann jetzt auch.
Und, äh, keine Ahnung, ich würde sagen, wir verlinken einfach auf diese Seite.
Dann kann man sich das da angucken.
Äh, möglicherweise ist es so, Das ist so, dass man von den Pre-Render mehrere haben kann.
Ich guck mal, ob ich das hier so direkt sehe.

[9:01] Die Speculation Rules API ist aber, wenn ich jetzt richtig sehe, auch nur ein Draft Community Group Report.
Also, das ist so quasi der Facebook Post unter den Spezifikationen.
Ja, aber das ist ja bei Chrome schon öfters der Fall, dass Sachen, sagen wir mal, sehr frühzeitig schon mal sozusagen geprototypt oder auch geschippt werden.
Genau, also Hauptsache, man hat ein neues Feature und hintenher tut man noch irgendwie so ein bisschen Spezifikationstext, damit man sich sozusagen eine brauchbare Verteiligung...
Dass man sich nicht sagen lassen muss, man wäre der neue Internet Explorer.

[9:46] Genau, ob man wollte, ja. Aber die anderen wollten halt nicht.
Die hätten ja an dem Dokument mitarbeiten können. Das hast du ja schließlich auf die Facebook-Seite geschrieben und jeder, der da drauf ist, hätte das lesen können und hätte mitmachen können.
Eben. Ja, also das zu Prerender, genau. Ansonsten gibt's auch noch so, man kann ja auch noch so Sachen machen, wie, äh, also, du kannst ja dein, wenn du jetzt so einen statischen Seitengenerator hast, zum Beispiel kannst du eben hingehen und die Google Analytics API abfragen und dann kannst du quasi ableiten, okay, Leute, die auf der URL sind, surfen meistens auf jene URL weiter und dann kannst, also das ist ja so dieses, auch dieses speculative prefetching oder preloading und kannst dann entsprechende resource hint angaben in dein dokument rein rendern so aber ich finde es eine lustige coole idee aber ob man das jetzt in der praxis auch so machen sollte da bin ich noch nicht so überzeugt von es gibt sicherlich wo das voll sinnvoll ist also ich stelle mir jetzt irgendwie sofort was den siebenteiligen podcast wenn du, da in der Episode 4 den Link auf Episode 5 pre-renderst. Nicht die bescheuertste Idee.

[11:01] Bei einer normalen Webseite schaut mal, ob euer Treeshaking in JavaScript wirklich funktioniert.
Und dann werdet ihr sehen, dass es das nicht tut, und dann werdet ihr das reparieren, und dann ist es viel, viel schneller, und ihr müsst nicht mal was am HTML machen. Ja.
Genau. Sonst, hast du noch irgendwie Fragen zu den Resource-Hints?
Nö, also meine Frage wäre wirklich gewesen, ob meine gerade skizzierte Einstellung so, kannst du machen, wenn du alles andere fertig hast, ob das zutrifft?
Das scheint der Fall zu sein, damit bin ich happy.
Ja, absolut. Und ist auch wieder so eine Footgun, ne? Also, wenn alles wichtig ist, ist dann wieder nichts wichtig.
Und manchmal ist es auch eher sinnvoll, nicht Sachen zu priorisieren, sondern andere zu depriorisieren.
Was jetzt zum Beispiel mit diesem ... mit Fetch Priority, ich weiß nicht, ob das hier noch irgendwie kommt, aber da kannst du ja quasi, also, Ressourcen höher ...
Also, du kannst Priorität verändern im Ladeprozess.
Und anstatt dass du eben jetzt zum Beispiel irgendwelche bilder hochstufs oder so könntest du auch sagen ich stufe andere dinge runter das macht dann auch die, die pipeline sozusagen räumt die frei für für wichtigere dinge.

[12:13] Was halt von einer von einer welt ausgeht in der die handelnden entwickler das komplette, system im blick und unter kontrolle haben, ja genau das ist ja auch meistens nicht der fall ich erinnere mich an geschichten wie er zum beispiel jetzt kocht reis erzählt hat wieso eine startseite von sowas wie weiß ich nicht der bahn oder so man ja irgendwie sagen möchte irgendwie so ich will von nach um so und so viel uhr dass das wichtigste ist ist aber das kleinste warum einfach nur weil alle anderen dinger irgendwie bahn bonus hier und weil sie nicht deutschland ticket alles ja stakeholder sind und die burschen da alle so mit ranken muss ja plötzlich im politischen Prozess ausfechten und außerhalb eben einer Developer-Diktatur ist das mit der Fetch Priority halt schon schwierig zu implementieren.
Ja, und dann hast du vielleicht noch Micro-Frontends, die dann irgendwie noch aufgeteilt sind.
Das heißt, da gibt's dann vielleicht auch keine Gesamtaorchestrierung, was quasi solche Dinge angeht, untereinander.
Ähm, ja. Aber wer eben handcrafted oder die Möglichkeit hat, das zu tun für die Personen, ist das dann vielleicht interessant.
Ja, ich würd mich trotzdem vielleicht gegen ... Ich würd vielleicht sagen, wir brauchen einen ergänzenden Begriff zu Footgun.

[13:29] Also, weißt du, unter Footgun stelle ich mir wirklich so was vor wie das klassische C++-Ding, wo du was schreibst, was harmlos aussieht und was sofort zu einer massiven Explosion führt.
Und dann ist halt dein Fuß weg. Ja.
So Sachen wie irgendwie falsch prerendern oder irgendwie die Fetch-Priority durcheinanderbringen, das ist ja, sagen wir mal so, vom Effekt her ...
Du merkst nicht, dass dein Fuß weggeschossen wurde, meinst du?
Ja, ich bin mehr so im Formenkreis der Vergiftung oder so der krebserregenden Substanzen, weißt du?
Ist das nicht vielleicht mehr so eine art irgendwie webentwicklungs akrylamit oder irgendwie so ich es ist der schleichende tod.
Ja noch nicht mal halt irgendwie nur so weißt du so. Hätte auch was anderes essen können aber okay.
Ja du darfst mal ein burger essen aber in jedem tag burger ist es nicht gut für dich.
Genau ist nicht gut aber das merkst halt eben auch echt nicht unmittelbar und vor allem wenn du dann halt irgendwie ein tag kein burger ist dann ist auch nicht gleich irgendwie alles repariert so so in die richtung geht das halt eben du machst halt irgendwie so.
Ja, letztlich den Deckel auf von der Dose, die da sagt, ich kann irgendwie genau sagen, wann da was gefetscht werden muss und der wilde Browser hat da keinen Plan.
Ihr, ähm, schwierig, schwierig, würde ich sagen.
Ja, stimme ich dir zu.

HTML-Module

[14:42] Genau, dann haben wir hier einen Punkt, als Nächstes HTML-Module.
Da frag ich mich, ob damit die alten HTML-Module gemeint sind, die es früher mal gab, so im Zuge der Web Components V0 oder was.
Oder ob das jetzt was anderes ist.
Du machst irgendwie so, importierst irgendwas from so und so, und from so und so soll dann halt eben auch was anderes sein können als eine JS-File, nämlich halt eben HTML.
Okay.
Äh, ja. Und da frage ich mich dann nur, gibt's das nicht für JSON auch?
Und dann muss man da aber noch so extra Angaben machen? Und wenn ja, warum muss man das jetzt bei dem HTML-Dings nicht?
Ähm, ich weiß, was du meinst. Äh, wie heißt denn das noch mal?
Oder kann man nicht auch CSS mittlerweile per Module importen?
Äh, Moment. Da war doch irgendwas. Sekunde, Sekunde, Sekunde. Scroll, scroll, scroll.
Ah, genau. Was wir hier suchen, sind die ...
Was du gerade meintest, sind die Import-Attributes. dass du sowas machen kannst, wie import json from irgendwas.json und dann kommt da halt eben noch ne syntax hinterher, die dann sagt, welcher Dateityp das ist.
Mhm, genau.
So, und das ist ja, wenn ich das jetzt so richtig, wenn ich jetzt so mein ECMA-Skript richtig kenne, dürfte das ja auch wieder so ein klassischer Fall sein von, da ist ne syntax spezifiziert, aber was damit gemacht wird, ist ja plattformabhängig.

[16:05] Also, weil bei json, weil das ja Teil von JavaScript ist, dass das irgendwie Node und Browser gleich machen sollen.
Aber wahrscheinlich ist es so, wenn ich HTML im Browser importiere versus in Node importiere, oder CSS im Browser importiere versus in Node importiere, dass das schon unterschiedliche Effekte haben sollte.
Okay. Also, hab ich jetzt nicht gelesen oder so, aber wenn ich so daran denke, wie Module an sich funktionieren, macht das ja irgendwie Sinn, dass man den ECMA-Script-Standard so baut, dass alle Plattformen damit bespielt werden können.
Und diese Import-Attribute sind ja auch irgendwie schon Stage 3.
Und da hat man auch irgendwie schon Demos von gesehen und so.
Und das macht ja alles irgendwie viel Sinn.
Und wie jetzt da diese HTML-Dinger reinpassen, weiß ich nicht.
Weil die Syntax, die jetzt zumindest hier in dem GitHub-Repository ist, die passt da nicht zu.

[16:53] Nee. Aber macht natürlich Sinn, dass das irgendwie nicht irgendwie sich an ECMAScript hält.
Weil das im Prinzip ja nur in einem sozusagen Subset ein Subset an JavaScript-fähigen Engines relevant ist.
Naja, was du jetzt hier hast, ist ja ein ganz normales JavaScript-Import-Statement, wo halt nur die Dateiendung nach dem From eine andere ist.
Genau, und wenn man dann weiter runterguckt, dann müsste das ja im Grunde genommen doch JavaScript sein, was in dieser Datei drinsteht, korrekt?
Weil man ja dann im Prinzip ein Custom Element definiert mit dem, was man importiert.

[17:33] Also ganz abgefahren. Naja, nee, das Ding ist halt eben, erstmal, was müsste das sein?
Wie immer gibt es keine Spezifikation bei dem Zeug, das haben halt nur irgendwelche Nasen mal sich so eine MD-File irgendwo auf GitHub zusammengeschrieben, ne?
Ja. Also, keine Ahnung, wie das so funktioniert. Aber, ähm, was die halt tatsächlich...
Also, wie das in meinem Universum funktionieren sollte, ist halt, man kann diesen, äh, dieses Attribut bei dem Import angeben.
Also, das hier ist halt eben ein Import irgendwas from so und so HTML. Mhm.
Und dann gibst du halt eben an, dass das ein HTML-File sein soll.
Und dann kann ja die Plattform definieren, wie sie damit umgehen will, dass es ein HTML-Part ist.
Also, Import ist ja bloß eine Syntax.
Und der Lademechanismus geht davon aus, dass es JavaScript ist, und diese Attributsyntax ist dazu da, um zu sagen, was ist, wenn es kein JavaScript ist, damit hier unterschiedliche Plattformen unterschiedliche Dinge damit machen können.
Und wenn ich jetzt sagen würde, ich wollte HTML importierbar machen in JavaScript über die ECMAScript-Modul-Syntax, würde ich sagen, klingt gut, aber verwende doch den gleichen Ansatz wie bei Jason, dass du hinten ein Attribut dran klemmst, das sagt, das soll bitteschön verarbeitet werden, als in dem Fall HTML, nach den Regeln der Plattform, in dem Fall des.

[18:42] Browsers. Ja, das würde Sinn machen. Und ich habe jetzt mal auch hier endlich gefunden, was man da in diesem HTML, also was da drin ist, das man importiert.
Und das besteht aus einer Template und einem Script-Type-Module, in dem sozusagen die Custom-Element-Klasse definiert wird.
Oder das JavaScript dazu. Und man hat in der Template dann einen Style-Tag mit dem dazugehörigen Style und eben dem Markup.
Das heißt, es ist so ein bisschen am Ende wie so ein View-File von Vue.js oder so.
Oder so, also so ein...
Single-File-Auto. Genau, immer noch mit dem Drive. Man möge doch HTML Elemente, also Web-Components, möglichst in HTML definieren können.

[19:33] Das scheint mir so der Motivator zu sein, weil du hast recht, das sieht halt exakt aus wie ein View-File, ein bisschen Skript, ein bisschen Style, ein bisschen Template.
Und sozusagen ist dann dieser HTML-Import die Möglichkeit, das alles einfach zu importieren.
Ja, genau. Und wenn ich hier in Chrome Status gucke, dann sind angeblich nicht nur die Chrome-Leute finden das gut, sondern auch die Firefox- und Safari-Leute.
Während wir Web-Entwicklerinnen und Entwickler da Mix-Signals geben.
Vor allen Dingen würde ich gerne wissen, was so der ganzen Browser-Hersteller-Diskussionsgrundlage ist.
Weil einfach so jetzt in den Browser so ein magisches Ding einzubauen, dass wenn die Datei mit HTML endet, Ja, das ist natürlich Quatsch, also es müsste ja schon irgendwie, weil nicht jede HTML oder nicht jede Datei, gerade im Web, endet ja nicht auf dieser Erweiterung.
Es könnte ja auch HTML sein, es könnte gar nichts sein, es könnte groß sein.
Es spricht nichts dagegen, das mit XML, mit der xHTML5 zu machen, außer halt eben, dass das keiner kennt. Aber man kann und sollte das machen können.
Ja genau naja das heißt also im grunde so für uns ist das.

[20:51] Also, wir verstehen, wofür es gut ist. Ich find's, glaub ich, auch in Ordnung.
Ich glaub, es hat halt auch nicht das Problem, dass die alten HTML-Imports hatten.
Weil da war's ja, glaub ich, so, dass quasi dieses Parsing gestoppt ist, bis das importiert war.
Das ist halt hier nicht der Fall, weil man kann nur aus einem ECMAScript-Modul heraus importieren.
Und das ist ja quasi per Definition schon asynchron.
Mhm. Genau, und uns fehlt im Grunde nur diese Annotation, die wir eben auch für JSON kennen.
Und da wurden dann bei uns Forms, die halt hier nicht gibt.
Naja, und einen Einwand hätte ich auch noch.
Nämlich, okay, das sieht aus wie eine Viewfile, das heißt, gegebenenfalls bin ich gewohnt, dass meine Komponenten so aussehen.

[21:39] Aber warum würde ich die so aufbauen wollen? Warum ist das der offizielle Weg, eine Komponente zu bauen, und nicht irgendein anderer?
Es gibt ja genug Prior Art, wo man sagen könnte, das ist auch eine Art und Weise, Komponenten zu schreiben, die sich als sehr sinnvoll erwiesen hat.
Das ist einer von vielen, das ist Vue.
Das funktioniert gut und ist total toll und alles supi. Ja, das kann ich dir aber sagen.
Der Grund ist einfach nur Performance.
Also du musst, also wenn du so was machst, dann willst du wahrscheinlich nur eine Datei importieren müssen.
Und da muss alles drin sein, was du für diese Komponente brauchst.
Weil ansonsten ist das ja eine absolute Shitshow sozusagen.
Äh, vom Ladeprozess her. Und, äh, genau, ob du jetzt ...
Ob das Template sozusagen parallel zum Script-Type-Module liegt oder nicht, das, äh ...
Das kann man debattieren. Aber ... Ich wollt's grad sagen, es macht keinen Unterschied, ob das ein Template-Tag in einer Fake-HTML-Datei ist oder ob das ein Template-String in meiner Klasse ist.
Ästhetik mal außen vor, aber das macht doch eigentlich unterm Strich keinen Unterschied.

[22:45] Ja, vielleicht. Vielleicht ist das ja auch gar nicht so, vielleicht ist das ja auch nur eine mögliche Ausprägung.
Aber ich denke, was auf jeden Fall fix ist, ist eben die Tatsache, dass man alles in eine Datei reindonnert, wie auch immer.
Ja, aber warum mache ich das nicht jetzt mit JavaScript?

[23:07] Vielleicht weil JavaScript einfach kostiger ist zu parsen. Also so wie man ja zum Beispiel sagt, es ist nicht klug beim Hydraten deine Daten sozusagen direkt als Objekt zu shippen, weil der Parser einfach für das Parsen eines Objektes länger braucht, als wenn du zum Beispiel ein JSON-String schippst.
Ja.
Also, JavaScript ist eben einfach immer teurer als HTML oder was anderes.
Und darum kann ich mir vorstellen, dass es sinnvoll ist, eben das JavaScript, den JavaScript-Teil, der ein Parser und ein Just-in-Time-Compiler und was weiß ich was durchlaufen muss, so klein wie möglich zu halten.
Und darum würde ...
Also, weil du willst ja sagen, dann kann ich das HTML nicht als Template-String ins JavaScript packen, oder?
Ja, oder warum ist das nicht irgendwie so ein React-Komponenten-mäßiges Ding, wo ich einfach so ein Sprachkonstrukt habe, das exportiere ich, und das managt sich halt irgendwie selbst, und da ist alles drin, was es braucht, Templating und so weiter und so weiter, alles einfach, weil ich meine, die ganzen ...
Das kannst du ja trotzdem machen. Du könntest ja wahrscheinlich den Template-Teil weglassen und nur den Script-Type-Module-Teil drinlassen, und dann hat der das halt ...
Aber warum mache ich dann immer noch einen HTML-Import versus einfach einen normalen ECMA-Skript-Import, in dem ich das ja auch machen kann?

[24:37] Äh, das kannst du dann natürlich auch machen, klar. Genau, also das Ding ist halt eben, das tritt an mit einem neuen Feature gegen etwas, für das ich jetzt argumentiere, was ich jetzt schon habe.
Ich kann jetzt hingehen und ich kann eine Web-Component schreiben mit Template-Strings, ich kann jetzt hingehen und kann eine Raid-Komponente schreiben mit JSX, das dann auch noch getype-checkt ist und so was alles.
Team-Plattform sein wollen, das ist ja der Gegner.
Wir müssen geiler sein als die.
Und da kannst du natürlich argumentieren aus der Web-Perspektive mit so, das Plattform ist stabil und das ist ganz nett und ist irgendwie, keine Ahnung, late vielleicht, wahrscheinlich hast du recht, wenn ich jetzt mal so React dagegen halte.
Das kann ja alles sein, aber du musst halt so innen unmittelbar sozusagen auch an der Hello World Tutorial-Front irgendwie bestehen.
Und wenn du jetzt irgendwie sagst, okay, du kannst jetzt, du könntest jetzt theoretisch einfach eine Komponente importiert, die Javascript ist und da steht drin, wie das Ding aussieht.
Oder du könntest eine Komponente importieren, die HTML ist und in dem HTML schreibst du ein Tag und eine Klasse, die sind auf magisch indirekte Weise miteinander verbunden.
Typechecking ist halt leider nicht, aber wenn du es so machst und die neueste Chrome-Beta benutzt, dann geht das.

[25:44] Will mein inneres Team Plattform immer noch sagen, jawoll, super, brauch ich keinen Compiler, kann mir Facebook gestohlen bleiben.
Aber ich muss auch echt sagen, man macht sich das Leben dann auch ein bisschen schwieriger.
Mhm. Tja, keine Ahnung, ich hab grad überlegt, ob das irgendwie was mit Server-Side-Rendering verbessert.
Aber das wird's wahrscheinlich auch nicht tun. Ähm ...
Ja ... Ich weiß es nicht, keine Ahnung. Also, ich weiß gar nicht jetzt, wo nachher unsere Audio-Producerin den Schnitt packt. Wir haben ja vorhin ganz zu Beginn mal darüber gesprochen, irgendwie so Probleme nicht zu lösen, sondern zu eliminieren.
Ja. Wo man irgendwie sagt, keine Ahnung, ich baue meine Webseite auf eine Art und Weise auf. Wir haben die Working Draft Seite als Beispiel genommen, wo kein responsive Design ist, weil einfach so aus der Art und Weise, wie das Design gebaut ist, einfach das Ding sowieso auf jedem Formfaktor gut aussieht.
So, das ist Problem eliminieren versus lösen. Und da frage ich mich ja gerade so bei so dieser extrem heißen Diskussion um so Server-Side-Rendering immer, ob das nicht auch eine Instanz von Problemlösung versus Eliminieren ist.
Weil da man sich irgendwie um Server-Side-Rendering Gedanken machen möchte, ist das vielleicht nicht einfach sinnvoll, das Ding erst mal sozusagen vom Server-Side kommend zu gestalten, und dann so wie früher ein bisschen JavaScript-Interaktion über die ganze Geschichte drüber zu streuseln, statt sozusagen von Frontend zu starten und zu gucken, wie kann ich mein Frontend irgendwie dem Server begreiflich machen.
Wie wäre es mit einer HTML-Seite und irgendwie drei Web-Components für die komplizierteren Widgets?

[27:11] Revolutionär. Aber da hol doch ich halt auch keinen Hund mit hinten vom Ofen hervor leider.
Ja genau, das bekommen wir am Ende da an, wo wir mal irgendwann gestartet sind.
Das ist ja bei vielen Dingen so.
Aber ja, ich bin ja, so mache ich das ja in der Regel auch. Also da bin ich ja auch ein großer Fan von.
Das so zu machen, wie du gerade beschrieben hast. Ich würde es auch sehr gerne machen, aber mein Gehirn ist leider Single Page verpestet.
Verpestet. Ich muss da echt gegen ankämpfen.
Mhm. Aber ich probier's zumindest.
Ja, okay. Naja, dann lassen wir das mal hier so im Raume schweben. Interessant.
Also, merkwürdiges Ding.
Warum man das haben will, I don't know. Genau, liebe Hörerinnen und Hörer, sagt ihr uns doch auf Social Media oder in unserem schönen Slack-Channel, ob ihr eure schönen, einfachen React-Komponenten links liegen lassen würdet, wenn ihr dafür mit einem Import-Statement in ECMAScript eine HTML-Datei importieren könnt, ein bisschen HTML und ein bisschen JavaScript in einem extra Modul ist, das auf magische Weise zusammenspielt.
Äh, Punkt. Klingt das nach einem guten Deal für euch. Ja. Wobei du jetzt ein bisschen suggestiv gefragt hast, würde ich sagen.
Aber gut. Das ist für das Engagement auch ganz wichtig.

[28:25] All right. Dann, äh, hier, äh, sollen wir als Nächstes mal kurz Track-Element machen?

Track-Element

[28:32] Also hier Slots, weiß ich nicht, Slots hatten wir doch schon mal.
Hatten wir bestimmt im Rahmen von Web Components und Krams besprochen.
Lass uns das mal links liegen lassen.
Genauso, Track ist, äh, ähm, ähm, ähm, ja, Video-Element mit verschiedenen Sprachen, glaub ich.
Der Untertitel und, sagen wir mal, hinzugefügte Dinge.
Also Metainformation letztlich zum stattfindenden Medialelement.
Genau, aber Track ist das nicht auch quasi alternatives Audio-File und VTTs, also Subtitles?
Ist das nicht beides?
Für die alternativen Objekte, für die alternativen Quellen hast du ja Source.

[29:18] Ja, aber Source ist ja bei einem Video-Element jetzt zum Beispiel dann das wäre das Gesamt-Paket, also quasi Video und Audio, oder nicht?
Oder kannst du das auch trennen?
Aber wahrscheinlich, vielleicht hast du auch recht.
Das ist eine gute Frage, das weiß ich tatsächlich jetzt aus dem Stand nicht.

[29:39] Ja, genau. Ich gucke mal kurz bei MDN nochmal nach, aber da, ich meine...
M, D, N, L, O ist die Spezifikation.
Ich will wissen, was das Content-Model in den HTML-Specs sagt.
Dann weiß ich nämlich, was man ins Video-Element reinschreiben kann.
Dann kann ich rausfinden, was da drin ist.
Genau. Kind, Captions, Subtitles, Chapters, Metadata. Okay. Ich überlege gerade, wie das mit alternativen Sprach-Tracks ist.
Glaubt ihr das gar nicht? Kann das das Videoelement vielleicht gar nicht?
Also einfach ein anderer Audio-File zu dem einen zentralen Video-File dazu schalten?
I don't know.
Das find ich jetzt auch nicht, aber warte mal. Das crowdsourcen wir jetzt einfach mal.
An unsere Hörerschaft, uns das zu sagen. Interessant, also so spontan find ich jetzt auch nicht direkt raus, wie das funktionieren würde.
Mhm.
Was ich ja doof finde, ist, dass man ein Audio-Element nicht mit einem WebVTT irgendwie, Das ist, also man kann das im Browser nicht darstellen.
Also das geht nicht. Wenn du quasi ein transkribiertes Audio.

[31:01] On top von deinem Soundfile haben möchtest, dann hat der Browser da keine Möglichkeit, das anzuzeigen.
Das heißt, du musst dein Audio dann in einem Videoelement abspielen und dann geht das.
Ja, stimmt. Ich erinnere mich, dass ich mal recherchiert habe, welche HTML-Elemente definitionsgemäß unsichtbar sind und auch nicht sichtbar gemacht werden können. Audio war ja eins von den wenigen.

[31:27] Und dann ist ja auch so ein Use Case, das ist so Thumbnails, so Thumbnail-Previews anzuzeigen, wenn du, wenn du scrubst und also, dass du quasi schon mal sehen kannst, okay, so was passiert da in dem Video.
Und das wird ja auch über so ein quasi quasi speziell formatiertes VTT abgewickelt.
Mhm. Aber da hat sich irgendwie auch nie ein Standard für etabliert, was eigentlich auch schade ist.
Weil das willst du eigentlich ja fast immer haben, wenn du Video abspielst, so du das kannst.
Aber also, wenn jemand gefragt würde, möchtest du so was haben oder nicht, dann würde, glaub ich, die Mehrheit sagen, ja, bitte, Reviewsums, super.
Wenn du jetzt fragen würdest, so hey, möchtest du gerne ein Video-Element haben, wo du Preview-Thumbnails dir anzeigen lassen kannst, quasi mit dem Cursor zum Beispiel über dem Scrubber bist.

[32:29] Oder sagen wir mal, wenn du sogar selber scrubst, weil in der Regel ist das Videonachladen ja nicht so schnell, und dann kannst du quasi schon mal zeigen, okay, das wär das Thumb an der Stelle, dann würden wahrscheinlich die meisten Leute sagen, ja, find ich gut, will ich haben. Mhm.
Und das gibt's halt nicht. Also, es gibt ja hier dieses Kind-Attribut bei den Tracks, und dann gibt's Subtitles und Captions und was weiß ich was alles.
Aber eben Thumbnails gibt es nicht. Und in der Regel machen das die Videoplayer aber alle, in dem du dann so ein Kind gleich Thumbnails übergibst, und dann ist das sozusagen ein unter der Hand Standard.

[33:06] Die zu verarbeiten oder einzulesen. Und dann hast du im Grunde einfach Zeitmarken drin und URLs zu diesen Bildern, zu den kleinen Thumbnails.
Also der offizielle Weg, das zu machen, wäre ja, wenn ich's richtig verstehe, man nimmt als Kind Metadata, Und dann baut man da ein Skript obendrauf, das das macht.
Würde wahrscheinlich auch gehen, ja. Wobei, kein Metadata, muss ich sagen, hab ich auch noch nicht.
Also, ist mir noch nicht über den Weg gelaufen bisher.
Ja, das sagt halt ja, dass das Metadata definitiv etwas ist, was im Browser nichts macht, definitionsgemäß.
Aber so der offizielle Angriffsvektor ist für, ich will JavaScript mit einem Track verbinden.
Mhm. Das ist die Idee. Das wäre ja sozusagen der richtige Weg von jetzt tatsächlich einem Thumbnail sehe ich jetzt in irgendwelchen Specs, nehme ich nix.

[34:06] Ja. Aber das Format ist halt dann, das halt so eine Ausprägung von VTT ist relativ einheitlich bei allen Playern.
Also es ist jetzt nicht so, dass wenn du den JW-Player nimmst, der das ganz anders serviert braucht als der Playa-Player oder so, die sind sich da irgendwie alle einig.
Nee, das ist ja auch ein ordentlicher Standard, das WebVTT. Nee, aber die WebVTT-Ausprägung für die Thumbnails.
Mhm. Zum Beispiel.
Okay. Also, das ist dann ... Hm. Und warum machen die es nicht richtig?
Das ist ja sehr originell.

[34:45] Ja, ich meine, ich denke halt auch so, im Sinne von Paving the Cove Path, müssten die ja eigentlich mal hingehen und dann dafür dedizierten Track-Element irgendwie noch spezifizieren.
Genau, weil ich wette, dass die Player, du hast gesagt, die machen's relativ einheitlich, ich wette, sie machen's nicht einheitlich.
Sodass man da wahrscheinlich schon ein präemptives Nootools-Pullen diagnostizieren könnte.
Wir machen das schon einheitlich.
Machen die es einheitlich, einheitlich? Also, dass du jetzt sagen würdest, du, Shep, stehst mit deinem Namen dafür, dass man das, was die jetzt machen, eins zu eins in die Specs gießen könnte, und das funktioniert überall einheitlich.
Ja, vielleicht gibt's irgendeinen, hast du nicht gesehen, PlayerJS, der das irgendwie anders macht.
Aber was ich so bisher, dem ich begegnet bin, Da musst du keine Anpassungen an diesen Dateien vornehmen.
Du kannst den Player wechseln, und das funktioniert dann weiter. Mhm.
Trotzdem riskant, nicht den offiziellen Weg zu gehen, wenn's einen gibt.
Weil wenn das offiziell zu einem Kind erhoben wird, nämlich Thumbnail, und da sind wirklich kleine Abweichungen drin, dann wird's spannend. Mhm.

[35:51] Dann ist das ein Mutuals-Problem, aber auf HTML-Ebene, das wäre ja mal was Neues.
Ja. Brauchen wir auch mal.
Haben wir ja für JavaScript gehabt, haben wir jetzt für CSS gehabt.
Ja. Auch immer noch für HTML. Also deswegen, wenn ihr eine Library schreibt und euch irgendwie die Möglichkeit besteht, einen offiziellen Weg zu beschreiten, um eure Metadaten unterzubringen, Data-Attribute, Custom-Elements, irgendwie was, was irgendwie so der offizielle Weg ist, wo die Spezifikationen euch garantieren, in diesen Namespace-Creation wir definitiv später nicht rein, dann nehmt den, weil sonst habt ihr möglicherweise mit eurer Library Erfolg Und dann kommen irgendwelche Spezifikationsänderungen und dann seid ihr im Mootools.
Was ja auch irgendwie cool ist, auf eine gewisse Art und Weise.
Man ist auf jeden Fall dann legendär.
Und das ist ja sicherlich nicht... nichts.
Mhm. So, dann hier, MathML, nie benutzt. Du?

MathML

[36:46] Äh, nein, der geht nicht.

[36:50] Alles was ich in mathe kann habe ich irgendwie mir als autodidakt angearbeitet angelehrt und deswegen kann ich da diese ganzen die ganzen formelkram auch nicht lesen.
Schweige dann schreiben andererseits ist es ja schon so ich meine das ist das im web nicht gibt es schon ein bisschen arm weil.
Ist halt ein etablierter standard.
Ja, ich glaube, ja, es ist auf jeden Fall, ich glaube, die meisten Browser können es und Chrome hängt da hinterher, oder? Wie ist das?
Ich sehe gerade, mittlerweile sieht die offizielle Kompatibilitätstabelle einigermaßen gut aus.
Ja, das ist ja auch so ein crowdgefundetes oder co-gefundetes Projekt gewesen, also auf OpenCollective und umgesetzt oder implementiert hat es dann wieder hier Egalia, was ja sozusagen sowas wie Söldner, für Browser-Feature implementierend sind.

[37:46] Das heißt, wenn ihr in einer großen Firma arbeitet und immer schon fandet, dass irgendein Standard wie zum Beispiel die HTML-Imports endlich mal in Browsern implementiert sein sollten, dann könntet ihr da anrufen bei denen, den Geld hinlegen und dann würden die das, in die Engines einbauen, so ihr denn wolltet.
Aber dann sieht es doch in der Kompatibilitätstabelle eher gut aus.
Die Häkchen in der Kompatibilitätstabelle bei Firefox haben einstellige Versionsnummern.
Mh, hab ich gesehen, ja, Version 4 war das, ne? Jo.

[38:27] Genau, das Einzige, was mir sonst noch einfällt dazu, ist, dass ja der Browser bei so Sachen wie SVG und MathML, ähm, dass er dann sozusagen die Engine wechselt.
Also, wie er Sachen parst. Und dass ja auch immer gern genutzte Einfallstore sind, um, äh, Cross-Site-Scripting-Krempel in den Browser zu bringen, Indem man eben sozusagen auf SVG wechselt, dann irgendwas reinsteckt, was im Grunde in HTML kein Problem wäre, aber in SVG dann doch.
Und vielleicht gibt's das auch für MathML oder auch nicht. I don't know.
Ich würd annehmen, dass das ein bisschen weniger dramatisch ist.
Also SVG ist ja im Prinzip alles.
Also, das inkludiert ja CSS und Scripting und alles. Und ich glaub, MathML ist da deutlich, sagen wir mal, mal restrainter, was das Feature-Set angeht.
Und ich meine, was ist die Alternative? Die Alternative ist, du holst dir sieben Megabyte JavaScript und drennst das auf ein Canvas.
Ist jetzt auch nicht automatisch supersicher. Nee.

[39:31] Genau, es gibt übrigens einen schönen SVG-Angriff, weil du hast ja das Animate-Element in SVG.
Und das animiert aber ein Parent.
Mhm. Und da kannst du quasi dann animieren von On-Click harmlos zu On-Click nicht mehr harmlos.
Und weil das On-Click aber ja nicht, also das ursprüngliche On-Click ja harmlos ist, wird es dann in der Regel durchgelassen und dieses Animate-Ding, das hat irgendwie dann keiner auf dem Schirm.
Hmm.
SVG ist echt, also von Hand SVG schreiben ist schon ein Sport.
Habe ich mal vor einiger Zeit probiert.
Mhm.
Also ist sehr anders und sehr schwierig. Und am Ende sind Webbrowser die einzigen, die das irgendwie dann ordentlich darstellen.
Mhm. Weil sämtliche Imageviewer und so kann man komplett in die Tonne treten.

[40:25] Äh, mach ne Webseite mit HTML und CSS. Das ist auch quasi... Das ist besser.

Focusgroup

[40:30] Genau, dann Focus-Group-Attribut haben wir als nächstes. Das finde ich, glaube ich, gar nicht schlecht.
Da geht es quasi darum, dass du sagen kannst, hier in diesem Element, das ich damit auszeichne, da soll es möglich sein, mit Cursor-Tasten den Fokus zu wechseln zwischen den unteren Elementen.
Das gab es auch mal als Directional Navigation. Ich glaube, der Operator das sogar unterstützt, Weil der ja auch auf so Fernsehern und Nintendos drauf war und die ja in der Regel nur so Richtungstasten hatten.
Und da konntest du dann eben auch mit den Richtungstasten navigieren.
Genau, find ich ganz gut. Und hast du ja auch manchmal bei so was wie Selects oder so, da kannst du ja auch mit ...
Da musst du ja dann nicht die Option Ant haben, sondern da kannst du ja dann deinen Cursor verwenden.

[41:25] Genau. Ja, ist nett. Müsste mal jemand spezifizieren, ne? Mhm.
Ist in Chrome bereits drin, so hinter dem Fleck? Wird also schön ausprobiert. Ist auch so im Origin-Trial.
Was ist die aktuelle Chrome-Version?
Ich hab keine Ahnung. Bei mir steht nur aktualisieren. Da steht aber mal...
Ich benutze ja Firefox neuerdings, deswegen weiß ich das gar nicht.
Warte mal, hier, Hilfe-Seite.
Herrschte da nicht früher immer drin, was das für eine Chrome-Version ist? Äh, doch schon.
Oder über oder sowas. Über Chrome. Da genau. Chrome Version 116 habe ich hier.

[42:03] Und das ist im Origin-Trial auch schon ewig lange drin. Also ja, wie immer.
Ein Feature, das kommt. Das mehr oder weniger unilateral ausgerollt wird.
Jawoll. Web-Entwickler sagen positives Signal. Safari und Firefox sagen gar nichts.
Es gibt keine Spezifikationen, aber der neue Internet Explorer baut es schon mal ein. Na gut.
Mhm. Das ist ja auch wieder hier Teil von von der Open-UI-Truppe. Könnte ja auch sein.

Exclusive Accordion

[42:27] Genau, auch von der Open-UI-Truppe ist dieses Exclusive-Accordion.
Da hatten die ja auch letztens eine Umfrage gemacht, wie sollte das funktionieren?
Also, was das machen soll, ist, du hast Details-Elemente, Details-Elemente, und deren ursprüngliche Idee war, gib denen ein Name-Attribut, und dann, Wenn das Name-Attribut da ist und das auf mehreren Details-Elementen ist mit dem gleichen Namen, dann ist das sozusagen das Signal für den Browser, dass die exklusiv sind.
Und das bedeutet wiederum, du kannst immer nur eins von denen öffnen.
Anderen sollen dann sich.

[43:14] Oder sagen wir mal, eins kann am Anfang offen sein, und was dann passiert, ist dann Teil der Umfrage gewesen.
Also sollen dann, soll das Geöffnete sich schließen, wenn du ein anderes öffnest?
Soll das eins schon Geöffnetes aufbleiben, wenn du ein anderes öffnest?
Und überhaupt, ist das sinnvoll, das mit Name zu machen oder nicht?
Und am Ende stellt sich aber, und genau, und was ist denn, wenn der HTML-Autor die gruppiert, aber dann mehr als eins zu Beginn als mit dem Open Attribut versieht.
Also was soll der Browser dann machen? Soll er dann irgendwie das Letzte öffnen?
Wie das bei Checkbox der Fall ist, oder soll er das Erste öffnen, wie das vielleicht bei Autofokus der Fall ist?
Und am Ende stellt sich heraus, dass das ein ganz schön schwieriges Problem ist.

[44:06] Okay, interessant. Ich hätte nämlich jetzt erwartet, dass die Entstehungsgeschichte einfach so ist.
Da sitzen so zwei irgendwie so leute zusammen einer zieht am joint und sagt dann so wie wir hier was was wäre, ja quasi und fragt dann so was wäre wenn wir wenn wir radio buttons hätten aber sie werden details elemente das ist doch ein exklusives accordion oder ja im grunde ja und das verwendet ja auch tatsächlich dat Name-Attribut.
Ja.
Warum gehst du nicht hin und sagst irgendwie radio buttons copy paste und dann tauscht der Input gegen Details aus?

[44:50] Ne, ich glaube das wäre ja auch das, was sie gerne gemacht hätten.
Aber warum ist das dann so haarig, wenn man doch einfach sagen könnte, wir nehmen das so wie es schon ist und funktioniert und ja, das hat irgendwelche Trade-offs, aber zumindest sind die Web-Entwicklerinnen und Entwickler daran gewöhnt. Und man kann ihnen einfach sagen, hey, dieses neue was du da hast, oder dieses neue Feature, was du da hast, das ist wie Radio Buttons, nur halt mit Details-Element.
Ja, okay. Kann man machen. Dann gibt's jetzt ein paar Fragen.
Was wäre, wenn du oben in deinem HTML-Dokument HTML-Dokument ein offenes Details-Element mit einem Namen hast.
Dann kommt ganz, ganz viel HTML und am Ende kommt noch mal ein Details-Element mit dem gleichen Namen, das auch ein Open Attribut hat. Was machst du dann?
Das gleiche wie Radio Buttons. Das heißt?
Weiß nicht, aber ich würde das nehmen, was Radio Buttons machen.
Genau, das heißt, das erste würde dann geschlossen werden wieder.

[45:42] Das würde der Browser aber erst merken, nachdem er vielleicht ein paar Sekunden lange HTML übertragen bekommen hat.
Wenn das das ist, was Radio Buttons machen, ist das, was die Webentwicklerinnen und Entwickler erwarten.
Aber dein initialer Viewport ist halt eben oben, ne? Das heißt, auf einmal kollabiert dann das offene Details-Element, und ist dann wieder geschlossen.
Das kriegst du doch genauso hin, wenn du irgendwie Input, Type, Radio oder was das ist, hast, plus irgendwas anderes, und dann machst du da auch eine Check-Pseudoklasse rein.
Je nachdem, was Phase ist, wird was angezeigt oder nicht. Aber, Peter, das soll man doch nicht machen.
Und das macht auch keiner. die da irgendeine Demo bauen, die komplett ohne Javascript irgendwas macht.
Aber wenn das das Argument ist, dann würde ich ja genauso gut sagen, was auch niemand macht, ist ein Details-Element mit einem Open Attribut, sieben Gigabyte HTML und ein weiteres Details-Element mit einem Open Attribut.
Okay, dann habe ich jetzt den nächsten Use-Case für dich.
Bring it on! Du hast ein Details-Element mit, keine Ahnung, Name Peter, das ist offen.

[46:45] Und in diesem Details-Element hast du ein Details-Element mit Namen Peter, das ist auch offen. Was machst du jetzt?
Das ist eine sehr gute Idee.
Äh ... Siehst du? Ja, nun ... Es ist ja nicht alles Blödsinn, was an Fragen aufgeworfen wird.
Und das ist tatsächlich ein sehr gutes Argument, weil das gibt's ja mit dem Radio-Button nicht.
Man kann ja nicht Radio-Buttons in Radio-Buttons machen. Genau. Ja.
Äh, ja. Dadurch, wenn du quasi nur das letzte Auftreten öffnest, müsstest du ja dann das Eltern-Details-Element wieder schließen. Mhm.
Und dann wär gar keins mehr offen, weil das Offene ja in dem geschlossenen Details-Element drin steckt.
Ja, das stimmt.

[47:24] Ja, das klingt gut, Kram-Kram im Kopf, keine Ahnung, aber da kann man doch bestimmt ne Lösung finden.
Also, es gibt ja so viele Sachen, wo wirklich so Dinge sind, also, da könnte man theoretisch irgendwie entscheiden, dass z.B. jedes Detailselement dann wiederum ein neuer Scope ist.
Es handelt sich ja nicht um Formularfelder, d.h. das Name-Element kann mit neuer Semantik aufgeladen werden und man könnte halt eben für diesen Verschachtelungs-Edge-Case einfach sagen, jedes Detailselement ist ein eigener Scope.
Also kann ich halt irgendwie ne Foo-Gruppe, inner Foo-Gruppe, inner Foo-Gruppe haben.
Wäre jetzt meine erste Idee.

[47:56] Ja, genau. Aber du musst halt ... Du musst eben was am Parser ändern.
Also, du kannst nicht die ...
Sagen wir mal, einfach nur den Code nehmen, den du für Checkboxen benutzt, und den da eben anwenden oder nutzen für.
Nee, den Code definitiv nicht. Definitiv muss der Parser geändert werden.
Aber die Leitlinien für HTML-Design sagen ja, die Prioritäten sind erst die User, dann die Developer, dann die Spezifikateure, dann die Theorien.
Ja, also ich denke auch, dass der Parser geändert werden muss.
Also da führt kein Weg drumherum, wenn man das Feature haben möchte.
Ich glaube, ich würde das Ganze ...
Ich würde eher so was wie ein Details-Group-Element ...
Also das fände ich, glaub ich, besser, anstatt überall den Name draufzuklatschen.
Sondern es ist einfach klar, es gibt die Details-Group.
Und so wie unter T-Body eben nur TRs eingehängt werden dürfen, darf als Kind von einem Details-Group-Element nur ein Details-Element sein.
Und ... Warte mal, das Spielchen können wir noch andersrum spielen.
Was ist, wenn ich eine Tabelle reinschreibe?
Hm, na ja, dann müsste der Parser eben das verwerfen. Oder er müsste die Tabelle dann, wie es ja auch häufig der Fall ist, quasi erst mal im Speicher behalten und nach dem Schließen des Details-Group-Elements dann ins DOM einfügen.
Das hast du ja auch bei ...
Wenn du so verkorkstes HTML schippst, wo Dinge ineinander verschachtelt sind, die nicht sein können, dann macht er das ja auch so.

[49:26] Okay, na gut, es ist auch relativ einfach, weil du da ja nicht mit, sagen wir mal, bestehendem HTML dich kompatibel halten musst, sondern du kannst ja tatsächlich neue Regeln erfinden in dem Fall.
Klingt mir auch wirklich wie die bessere Variante, plus, also ich stelle mir sicherlich vor, das ist eine super Idee, das Details-Element, da bin ich ja sowieso ein extrem großer Fan von, weil null JavaScript, ein Club-Widget, wunderbar. Ja.
Und Details-Group wäre sozusagen einfach die logische Evolution davon, plus, was man ja machen könnte, wäre zu sagen, Man kann dieses Details-Group-Element ja komplett un-customizable machen.
Man könnte ja wirklich sagen, das Details-Group macht halt wirklich nichts als das.
Es hat keine Attribute, das hat keine JavaScript-API, kein nix.
Und wenn man sein Attribut irgendwie fancy animieren möchte, dann baut man halt eben sein eigenes Details-Group-Ding da drumherum und baut ein Custom-Element dafür.
Und das wäre dann sozusagen die Accordion-Plugin-API. Das gefällt mir eigentlich auch sehr gut.
Mhm. Ja. Und genau, ansonsten wär ich eben auch dafür, eben eher das erste offene Details-Element zu rendern und es dabei zu belassen.
Einfach weil du sonst halt riesen Layout-Shifts hast und das auch von ...
Also so, äh, auch von der User-Experience halt scheiße ist, ne?
Also, das fällt ja so in diese gleiche Kategorie rein.
Also, nicht nur, dass der Browser dadurch doppelte Arbeit hat, weil er irgendwann später merkt, alles irgendwie Relay-outen, sondern du hast eben auch.

[50:50] So wie bei Core Web Vitals, wenn du einen hohen CLS-Wert hast, ist das halt doof.

[50:57] Und in die Kategorie fällt das ja letztlich auch, wenn du ein Details-Element hast, das erst mal da ist, und dann hast du da Content drin, und du willst das vielleicht klicken, und in dem Moment geht das Ding dann zu, und du siehst was ganz anderes.
So, wer will das?
Du kannst ja, ob's angezeigt werden soll oder nicht, erst entscheiden, wenn du durch bist.
Ja, genau.

[51:22] Naja, mal sehen, wo die damit hinkommen. Ich glaube, es war auf jeden Fall gut, dass sie diese Umfrage gemacht haben, weil eben dieses ganze Feedback kam und sich herausstellt, dass das Ganze eben doch ein bisschen komplizierter ist.
Ja, also wir haben den Pull-Request für dieses Name-Attribut tatsächlich auch in den Shownotes verlinkt.
Dass man sich wirklich mal die ganze Debatte reinziehen kann, wenn ihr das möchtet.
Cool. Genau, dann haben wir hier Model. Hast du davon schon gehört?

Model-Element

[51:56] Von dem Model-Element? Äh, warte, warte, warte, warte. Äh, nee, hab ich tatsächlich noch nicht.
Das ist dieses 3D-Zeug.

[52:06] Genau, das ist jetzt ganz neu und gibt's, glaube ich, nur in Safari.
Moment Chef wir müssen wir müssen wieder wir müssen wirklich mit mit mit Existenz das müssen wir glaube ich ein bisschen genauer noch abgrenzen.
Ja, okay, es wird, wie soll man es ausdrücken?
Existenzstufe Draft Community Group Report. Also, das ist mehr als jetzt bei hier.
Was war das, bei Focus Group?
Vielleicht auch Brain Fart.
Möglicherweise. Ich weiß es nicht. Möglicherweise. Erzähl, wieso ist das ein Brain Fart?
Also, bei Safari ist es ja häufig so gewesen, dass was die an Features einführen, im Prinzip von Wünsche anderer Abteilungen sind.
Mhm. Und das ist bei dem Model-Element eben auch so. Und zwar kommt das von der Vision-Pro-Geschichte.

[52:54] Dass du quasi im Browser 3D darstellen kannst.
Und ich meine, dass es eben bei diesem Model-Element so ist, dass du in Prinzip komplette Kontrolle abgibst an das Vision-Pro, wie, was, wo möglich ist darin und was nicht.
Und das hat wiederum dann auch seinen Ursprung darin, dass du, glaube ich, eben aus Privacy-Gründen, also da achtet ja Apple stark drauf, und deswegen sollst du eben nicht mitbekommen, wohin Leute gucken, eben 3D-Raum und all so Zeugs.
Das ist so die gleiche Geschichte, wie als sie damals angefangen haben, so CSS-Transformationen und Zeug einzuführen, weil sie auch so im Prinzip ihre Software supporten wollten, IT-User und Konsorten waren das doch. Ja, oder auch diese Spiegelung.
Das das ist ja auch was das können die webkit oder die browser mit webkit ursprung aber das auch kein standard das kommt dann so aus aus deren hier apple books oder wie das heißt und itunes natürlich cover flow so die geschichten.
Da gibt's noch einiges mehr, gerade im CSS-Bereich. Ja.
Ja, ich find's ansonsten, weiß ich nicht...

[54:17] Von mir aus, wenn die das machen, werd ich's jemals benutzen, wahrscheinlich nicht.
Ja, es ist halt so eine Sache auch...

[54:27] Also, kannst du mir den Use Case noch mal erklären? Ich hab das, glaub ich, nicht ganz verstanden, wofür ich das Model-Element haben möchte.
Es ist eigentlich so was wie eine WebGL-Canvas oder eine, was benutzt man mittlerweile, WebGPU-Canvas, nur in Markup-Form und dann eben mit der Möglichkeit, das abzuschotten vom Zugriff, sodass man nur sagt, hier, Browser, hier ist ein 3D-Raum für die Vision Pro.
Ihr seid dran, ich kann jetzt eh nix mehr machen. Canvas plus ein Soundrummer rum.
Genau. Genau, noch gibt's ja die Vision Pro nicht. Ich glaub, die ist ja noch nicht ausgeliefert.
Die ist ja nur vorgestellt. Und vielleicht liest man ja irgendwann mal Making-ofs und irgendwie Blogposts über dieses Model-Element und was die Leute damit so fabriziert haben.
Ja, Moment, ich muss noch ein bisschen...
Mal kurz eben gucken, dass ich das gepast kriege.

[55:30] Das hat ja im Prinzip den Anstrich von einem Media-Element. Oh Gott, die Spezifikationen bestehen nur aus Überschriften, wo nichts angegeben ist.
Es gibt ein Cross-Origin-Attribut. Was macht es? Nix. Es gibt ein Controls-Attribut.
Was macht es? Steht da nicht.
Es gibt ein Loading-Attribut. Ist halt ein Verweis auf ein offenes Issue offen.
Das ist es auch. Ich meine in den Safari oder WebKit, aber wahrscheinlich eher Safari-Release-Notes, hatte ich da mal was drüber gelesen.
Ja, aber da sind wir wieder in der Evolutionsstufe der Existenz 1 zurückgegangen, im Vergleich zu den Specs. Mhm. Hm.
Shep, was ist deine allgemeine Meinung zu dem ganzen Virtual Reality 3D-Brillenkram?
Hmm. Also ich hab ja früher 3D gemacht und ich hab auch stereoskopisches 3D gemacht und was weiß ich was alles.
Ich glaube, das sind so Non-Starter-less.
Also ich glaube, dass die das mit der Vision Pro cool gemacht haben und dennoch wird diese Vision Pro nach ein paar Wochen irgendwo in der Ecke liegen und man wird die nicht benutzen.
Und das würdest du auch auf andere 3D-Brillen ausdehnen?
Jaja, auf jeden Fall. Ich meine, die Vision Pro ist ja noch so die, also die ist ja wirklich, also ich würde schon sagen, dass die deutlich besser ist als das alles, was es gibt. Also Also ich habe auch mal mit dem hier mit der HoloLens, die durfte ich auch mal ausprobieren, auch richtig geil.

[56:58] Ist sicherlich mal hilfreich, in bestimmten Szenarien auf so was zu greifen zu können, aber in der breiten Masse seh ich das nicht.
Ich finde, man sieht das ja auch bei den Konsolen mit ihren Brillen und ihren Spielen.
Also, es sind schon viele, die sich das holen und die mal so ein Spiel damit spielen, und die auch das irgendwie okay finden oder gut finden.
Aber es ist jetzt nicht so, dass die dann total am Suchten sind und so zu mir kommen und sagen, Also, Spiele auf normalen Fernsehern sind Dreck.
Ich möchte jetzt nur noch ... Also, die Virtual-Reality-Dystopie des 80er-Jahre-Films manifestiert sich nicht so wirklich.
Nee. Dass man da in die Welt reingezogen wird. Genau, und man liest halt immer wieder so, dass es ja eigentlich im Prinzip nur daran liegt, dass die Technik noch nicht gut genug ist.
Also, das ist ja so der Dauerbrenner. Dass es im Grunde nur an der Raffinesse der Technologie liegt.
Aber ich glaube, dass das Konzept an sich einfach nicht massentauglich ist.
Also es ist ein Konzept, das zur rechten Zeit am rechten Ort hilfreich ist und gut, aber es ist nicht massentauglich.
Solution in search of a problem. Genau.

[58:10] Das ist so auch ein bisschen so mein Eindruck. Und was ich faszinierend finde, ist, es gibt halt so die Skeptiker, Also du hast ja nur kurz eben jetzt so meine Virtual Reality Credentials mal eben auch, ich habe auch schon mal so ein Ding aufgehabt. Hier, der Tobi Struckmeier hat mir mal so ein Teil aufgesetzt, das sah einfach nur aus wie eine überdimensionierte Sonnenbrille. Also das ist tatsächlich so Heino-Niveau. Also es grenzt an sozialverträglich, dass du einfach dieses Ding aufhaben kannst. Und da stöpselst du dein MacBook ein, dann hast du da irgendwie so, das ist auch relativ überzeugend und nicht so teuer und alles irgendwie total nett. Aber der, Punkt ist halt eben, das ist total nett. Ja, genau. Und halt wirklich voll das tolle Gimmick und da da spiele ich halt gerne mit rum, aber wie integrierst du das?
In die deine sonstige Realität rein. Ja.
Also Smartphone in die Realität integrieren, war ja super easy.
Das war wirklich das Produkt, das die Welt gebraucht hat.
Feine Sache, gar kein Problem.

[59:08] Aber die Teile, ist echt schwierig. Und, ich finde halt eben dieses Model Element ist ein ganz guter Indikator dafür, wieso viele andere diesen Bereich sehen.
Die haben nämlich nicht nur dieses, die sind nicht irgendwie so, wo wir jetzt ein bisschen skeptisch sind, und andere vielleicht sagen, ja, keine Ahnung, schauen wir mal, wird, glaub ich, bei speziell denen, die es dir zu verkaufen suchen, gar nicht in Frage gestellt, dass das die Zukunft ist.
Mhm. Das ist so definitiv der Fall, dass das überhaupt gar nicht hinterfragt werden muss.
Ja. Das ist so ein bisschen wie mit Second Life und dieser hier, ähm ...
Wie ist das hier, diese Meta-Geschichte von Metaverse?

[59:54] Ja, genau. Das sind ja auch so Absolut-Terror-Krepierer gewesen, beides.
Das ist genau das Ding, genau in die Kategorie fällt das auch rein.
So Metaverse, einfach nur, weil es schon lange Bücher gibt, in denen sozusagen diese Welt gemalt wird.
Die wird daraus automatisch extrapoliert, dass, also im Prinzip ist ja ohnehin eine originelle Idee, Snowcrash irgendwie als Handbuch zu verwenden, statt irgendwie als, mh, aufpasse.
Das ist das eine. Das andere ist natürlich auch einfach so, dass das so gesetzt ist.
Ja.
Das ist eigentlich das wirklich Spannende. Also, weil nette Technik und funktioniert voll gut.
Ich habe auch von der Sonnenbrille keine Kopfschmerzen bekommen.
Und ich könnte mir durchaus vorstellen, dass wenn ich irgendwie einen super speziellen Use Case habe, was mir der Tobi da erzählt hat, war, wenn ich jetzt an irgendwelchen Dingern arbeiten möchte, an meinem Laptop im ICE, aber das ist halt irgendwie super geheim.
Der arbeitet ja für eine riesige Consultingbude. Also, wenn der da jetzt wirklich irgendwie ultrakritisches Zeug macht, dann kann er das halt einfach direkt in seine Augen beamen, ohne es auf dem Bildschirm zu haben.

[1:00:52] Seh ich ein ist nicht der use case von so besonders viel. Ja ja ja oder keine ahnung dann hast du halt in der bahn einen sehr großen arbeitsbildschirm vor dir das vielleicht auch noch so nett aber.
So der nachteil irgendwie gar nichts mitzubekommen von der außenwelt also das stört mich halt auch immens und.
Aber das wichtigere ist, es löst halt wirklich nur sehr wenige Probleme, du brauchst das für sehr wenige Sachen.
Ja und dafür ist es halt auch dann sehr teuer, wenn das halt so ein 10-Euro-Ding wäre, dann würde ich sagen, okay, das ist halt angemessen für die Menge Probleme, die es gibt, die das löst, aber für so ein Once-In-Life-Problem, äh, weiß ich nicht, zwischen 500 und 3.000 Euro, oder was so eine Vision Pro kostet, auszugeben, find ich halt irgendwie Käse.
Ja. Ich hab hier so ein, äh, hier. Das Konzept des Escape-Room-Brettspiels, ist dir bekannt?

[1:01:51] Mh ... Nee, nicht so ganz. Also, du hast quasi ein kooperatives Spielgame in Form von so einer Detektivgeschichte.
Das besteht im Prinzip aus, du hast eine Box, da drin ist eine Plastiktüte, die reißt du auf, Es sind lauter Papiere und Beweismittel.
Da musst du anhand davon den Kriminalfall lösen.
Du kannst es nur einmal spielen, ne? So ist das doch auch immer bei den Dingern, oder?
Genau, das ist meistens so.
Ich hab hier eins liegen, das zocke ich mit meiner Freundin hin und wieder.
Das hat einen relativ großen Computeranteil, das ist auch gar nicht so ungewöhnlich.
Da musst du auf der Facebook-Seite recherchieren vom Verdächtigen, dass du rausfindest, wann war der und wo.
Du kannst mit dem Kommissar per WhatsApp reden. eben auch so einen virtuellen Tatort, den du dir angucken kannst.
Dann kannst du also auf dem Telefon fotografierst ein QR-Code ab und dann kannst du halt so mit so Motion-Sensor eben nach oben, nach unten, nach links, nach rechts gucken und dann kannst dann irgendwie so feststellen, aha, da ist irgendwie ein Einschussloch in der Wand.

[1:02:49] Und da kannst du auch ne 3D-Brille reinstöpseln. Uh! Das bietet negativen Mehrwert.
Du könntest einfach das Telefon in die Hand nehmen und dich einfach so auf deinen Platz drehen.
Dann kannst du halt irgendwie so alles sagen.
Und dann sagst du halt eben, da ist ein Messer, da liegt Blut.
Und dann schreiben deine Mitspieler das mit.

[1:03:09] Durch die 3D-Brille gewinnst du nix, außer halt Aufwand und noch mehr Kabel.
Alleine schon überhaupt ein Telefon permanent geladen, bei so einem Spiel dabei zu haben, ist so gerade eben noch okay und das noch zu verkomplizieren durch so einen otto.

[1:03:24] Das steht echt unter rechtfertigungsdruck wenn du mich fragst ja ja ja definitiv sehe ich auch so, und andere haben das ja auch erkannt also zum beispiel die holo lens ist ja jetzt auch die sollte ja eigentlich auch für jeder mann und frau sein, ursprünglich und da hat microsoft ja die strategie auch geändert und gesagt gesagt, nee, also wir bieten die weiterhin an, aber eben für ganz bestimmte Use Cases.
Und das waren auch solche Use Cases, die ich dann netterweise mal durchspielen durfte damit.
Also, dass du vielleicht mal, dass du in so einem Wissenschaftsmuseum irgendwie mal eine Mars-Landung machen kannst. Dass du vielleicht, wenn du irgendwo was zu reparieren hast, dass dann dein, keine Ahnung was, dein Motorrad und dann kriegst du dir, kriegst du daneben eingeblendet so was ist wo und welche Teile sind das und welches Werkzeug nimmst du und sowas. Dafür ist es schon okay und so platzieren die das und da kann ich mir vorstellen, ja, da kann man das einsetzen.
Ja, aber also ich würde sagen, da würde ich halt bei dem Museums-Use-Case auch echt noch mitgehen.
Also da halt wirklich was reinzubauen, dass dann die Kids was lernen und das ist spannend und so.
Super. Das kann dann gerne auch Abertausende kosten. Aber allein schon, wenn es so darum geht.
Ich will mein Motorrad reparieren.

[1:04:50] Ja oder vielleicht ein flugzeug oder was weiß ich wenn du so ein flugzeugmechaniker bist oder.
Ja da geht es dann schon eher richtig dahin aber auch da würde ich dann sagen da bewegst du dich halt eben bei dem flugzeugmechaniker und bei dem museum in ähnlichen budgetreichweiten aber ich stelle mir jetzt vor.
Ich schraube als kleinunternehmer oder auch als privatperson wirklich an meinem motorrad also dafür dafür nicht.
Genau, aber dann ist halt wirklich die Frage, wie groß ist da wirklich dann der Markt für diese Dinger?
Also wie viele Flugzeugmechaniker brauchen so ein Ding? Wie viele Museen brauchen so ein Ding?
Lohnt sich da wirklich dieses ganze Tremorium, das dafür gemacht wird?
Und braucht es dafür halt eben auch ein originäres HTML-Element?
Also ich finde das einfach nur super faszinierend, weil halt alle so, was heißt alle, sehr viele einfach so, es scheint halt zwei Camps zu geben, entweder so die ja, also, weißt du, so?
Und dann gibt's halt die, für die das absolut gesetzt ist, dass das die Realität ist.
Und dann gibt's halt sehr wenige von diesen Enthusiasten wie den Tobi, die halt einfach nur eine gesunde Nerdbegeisterung dafür entwickeln, wo ich auch sagen kann, das kann man so sehen.
Aber diese, das ist die Zukunft, TM, ist echt krass. Das hab ich zuletzt bei den Bitcoin-Bros gesehen. Ja. Nee, nee.

[1:06:04] Aber das scheint ja auch nicht todzukriegend zu sein. Das ist ja schon ein langes Thema.
Das war ja schon hier mit diesem VX1-Headset damals. Also, dass man mit Doom und Doom 2 in den 90ern benutzen konnte.
Da war das ja schon Thema.
Und immer hieß es halt, es liegt einfach an der Technik. Und hier der id-Software-Frontmann John Carmack ist ja dann auch zu hier, ähm, na ja, zu Facebook.
Und wie heißt der? Brillenmarke gewechselt.
Oculus. Oculus, genau. Ähm, und ist ja auch nicht mehr da. Also, ich glaube, der ...
Ich weiß nicht, ob er jetzt geheilt ist oder nicht, aber der war ja auch ein großer Verfechter dessen.

[1:06:47] Ich glaub, der ist einfach nur schlau genug, ein sinkendes Schiff zu erkennen.
Mhm. Wobei, insofern, da hatte ich nicht den Eindruck, dass die so sinken, also, ja, mal ein bisschen, aber damals noch nicht.
Nee, nee, ich mein, das Hype-Thema, von dem er so überzeugt war.
Mhm.
Also, ich glaub, der ist schlau genug und auch manns genug, um sich einzugestehen, upp, da hab ich ins Klo gegriffen, ich mach wieder was anderes.
Ja, ja, das auf jeden Fall. Er baut ja noch Raketen.
Siehst du, das ist wenigstens mal Technologie, das darf teuer sein, das braucht man, das ist nützlich, das ist ein Produkt, das hat einen klaren adressierbaren Markt und alles, das finde ich sehr viel sinnvoller.
Der soll Raketen bauen. Mhm.
Das macht Sinn. Soll nicht auf die Idee kommen, eine Social-Media-Plattform zu bauen, weil anscheinend ist die Kombination aus Raketen und Social Media, da funktioniert irgendwie was nicht, wenn man das zusammenmischt.
Genau, also ich weiß nicht, wie's dir geht. Hast du jetzt noch was hier in dieser Liste, was du interessant findest, was wir noch irgendwie besprechen sollen?
Also, es gibt natürlich immer noch irgendwelche Kandidaten.
Weiß nicht, Seamless, iFrames, ja, wollen wir halt immer schon haben.
Sanitizer, API, da können wir noch mal irgendwann vielleicht drüber sprechen, wenn diese ja grade im Umbruch befindlich.

[1:08:13] Wir haben ja auch den Freddy da mal vor, weiß nicht, wahrscheinlich wird das jetzt auch schon wieder zwei Jahre her sein.
Da kann man nochmal hinverweisen, worum es da in der Sanitizer-API grundsätzlich geht. Ja, ich denke, wir haben so die spannenden Sachen durchgesprochen. Also wie gesagt, das mit den Seamless-I-Frames wäre noch so das Letzte, was ich irgendwie sagen würde. Wäre was, was ich gerne hätte, aber ich kann sehr gut nachvollziehen, dass das von der Komplexität her.
Also erst mal, ist kompliziert. Und zweitens, gibt's, glaube ich, viele Möglichkeiten, ein ausreichendes Maß an Ziemlichkeit herzustellen, ohne dafür ein natives Feature zu haben.
Man baue sich einen Message-Buzz, man importiere die gleiche Zersetzer-Teil zweimal.
Geht auch. Wird für viele vollkommen okay sein. Ich meine, die gab's ja auch mal eine Zeit lang.
Und dann sind die ja wieder sozusagen rausgenommen worden.
Ich glaube, die hießen auch Seamless I-Frames.

[1:09:17] Und wahrscheinlich war's auch nur in Chrome. Genau, und dann gibt's ja noch dem nächsten Konzept von fenced iframes, die wiederum dann noch mehr Sicherheit bieten als die normalen iframes.
Also da kann man dann das, was du grade alles gesagt hast, also dass man irgendwie eine Crossframe-Kommunikation hat, über die man jetzt in deinem Beispiel irgendwie die Höhe des Inhalts des iframes dann an die äußere, die einbettende Seite kommunizieren kann, kann, die dann wiederum das iFrame entsprechend in der Größe anpasst.
Diese Dinge würden dann bei den fenced iFrames nicht gehen.
Was ich bei solchen Dingern halt immer denke, wenn jemand so was haben möchte.
Also man kann über HTTP auch andere Dinge transportieren als Jason.
Also man kann auch einfach sich ein Skript schreiben, dass sich ein Haufen HTML holt und das irgendwo reindampft. Und das ist okay.

[1:10:13] Ja. Also, dann hast du auch ein seamlesser. HTMLxLike, genau, das ist so eine Idee, oder ich habe eine Web-Component, die ich seit Ewigkeiten verwende, um so in meinen Slides Module zu importieren, irgendwie so, erkläre Web-Components, okay, importiere dieses Ding, und dann darunter dieses Ding, darunter dieses Ding, und dann ist fertig.
HTML-Import, das funktioniert ja auch wie ein seamless iframe, nur halt eben es ist halt kein eigener Kontext, sondern das ist halt irgendwie alles einfach so reingedampft und das ist völlig okay und das kann man halt eben auch machen, also ist halt schwierig, also ein iFrame ist ja irgendwie schon ein relativ guter Trade-Off aus so Isolation und das eingebettet und die Fenced-Variante, da müsste man wirklich mal die Security-Freaks Fragen, inwiefern die jetzt wirklich zwingend notwendig ist.

[1:11:00] Die unsecure Variante, dump einfach HTML in die Seite, geht ja auch.
Dann hast du noch Web Components und Shadow DOM, dann kannst du auch dein CSS scopen.
Da kann man ja schon viel anstellen.
Gibt's verschiedene Abstufungen, in die man sich rein opten kann. So sieht's aus.
Und deswegen ist es nützlich und schon ganz gut gelöst. Nö, ich würd sagen, wir haben jetzt über drei Revisionen, ganz gut abgerissen, was da im Bereich HTML so drin ist und was da alles so kommen mag und schon existiert.
Schon existiert und genau das sind jetzt ja quasi erstmal das ist ja sozusagen das inhaltliche brainstorming für den noch überhaupt gar nicht gelaunchten state of html das heißt also da wird dann in dem fall die lehrer die da den hut auf hat das ganze irgendwie destillieren aus dem input den die die Leute geliefert haben und genau, dann gibt's den irgendwann.
Dann werden wir das wahrscheinlich auch mal retweeten und retooten und re-axen.

[1:12:03] Und dann können wir ja, dann schauen wir mal, je nachdem, was dabei rauskommt, ob wir dann vielleicht, wenn die Results da sind, da auch nochmal reinschauen, wie wir das jetzt bei dem Set of CSS gemacht haben oder ob wir die Results sehen und sagen, okay, gut, haben wir im Grunde ja alles, alles gesagt, was zu sagen ist.
Naja, sagen wir mal so, ich glaube, wir zwei haben dazu wahrscheinlich schon ziemlich viel gesagt.
Aber dieser Podcast hat ja noch eine ganze Menge mehr Leute und eine ganze Menge mehr Gäste, die man akquirieren könnte.
Und die da vielleicht ganz andere Takes zu haben als wir.
Ja, stimmt. Ja, das ist so eine gute Idee. Dann machen wir das doch. So klug war das.

[1:12:41] Wunderbar dann beglückwünsche ich uns beide dazu dass wir das jetzt ins ziel manövriert haben das ganze.
Genau in nur vier mit in nur vier aufnahme sessions haben wir eine dreiteilige folge eingetütet das ist doch ganz großartig genau weil wir letztes mal ja vom weg abgekommen sind.
Genau und dies machen wir nach nur 34 minuten den weg wieder gefunden den wir beschreiten wollten so sieht es aus korrekt.
Alles klar. Dann vielen Dank.
Danke auch. Nächstes Mal wieder, glaube ich, State of CSS, zweiter Teil. Mal sehen, ob es auch zwei Teile werden, aber ich hoffe nicht. Aber vielleicht doch, man weiß es nicht.
Genau. Und wenn ihr Hörer und Hörer Anregungen, Fragen, Ideen habt oder mit uns schimpfen wollt, weil wir irgendeinen Vorschlag vielleicht nicht erwähnt haben, wie Bradging API oder Web-Share API, Dann macht das und könnt ihr auf X und Mastodon machen oder ihr hüpft in unseren Community Slack und alles findet ihr verlinkt auf unserer Seite.
Dann bis nächste woche macht's gut tschüss bis dahin tschüssi.

[1:13:53] Music.